Beiträge von klapperp

Hast du schon einmal gecheckt was aus dem Netzteil für Spannungen herauskommen?

Wenn sich das Floppy-Laufwerk zu langsam dreht wäre das mein erster Verdacht.

Liebe Grüße

// Peter

Hallo,

in aller Kürze:
Umwandeln lässt sich das Ganze nur mit dem gcc, den hab ich als Binary zusammen mit der glibc von einer der Freeware CDs bei mir installiert:

mvax3100.innonet.local> gcc --version
2.95.3

Insgesamt habe ich folgende Pakete übersetzt:

mvax3100.innonet.local> pwd
/freeware/src
mvax3100.innonet.local> ls -1
Mosaic-src-2.6
Mosaic-src-2.7b6
freeWAIS-0.1
freeWAIS-0.5
libjpeg

Makefiles hab ich für Ultrix auf der MicroVAX neue erstellt, weil es nie einen offiziellen Port für Ultrix auf MicroVAX gab. Ich hab die Makefiles von der von Ultrix für die DECstation genommen und angepasst.

Liebe Grüße,
// Peter

Liebe Community!

Der Konstantin hat nun zwei weitere Zeichnungen von der Sekundärseite der Schaltung von dem H7083-AB Power-Supply angefertigt. Dabei hat er auch noch einen Fehler in der ersten Zeichnung ausgebessert. So macht die Schaltung natürlich wesentlich mehr Sinn!

Was wir allerdings immer noch nicht wirklich verstanden haben ist, wie hier festgestellt wird, ob tatsächlich etwas angeschlossen ist (Strom verbraucht wird). Ich wäre dankbar dafür, wenn jemand erklären könnte, wie das hier funktioniert.

Ich hoffe die Pläne helfen jedenfalls auch euch dabei, eure Netzteile wieder in Gang zu setzen. Wir hätten den Fehler ohne das Reverse-Engineering vom Konstantin vermutlich nicht gefunden

Noch einmal ein aufrichtiges Dankeschön an Konstantin Grigoriadis für seine Hilfe!

Viel Erfolg euch allen bei der Reparatur eurer H7083 Netzteile.

// Peter

Hallo!

Noch einmal zusammengefasset was hier das Problem war: Das Netzteil lieferte nach dem Tausch der Kondensatoren alle Spannungen korrekt, allerdings auch immer sofort "Power-Good" und die LED war ebenfalls sofort an. Das führte dazu, dass die MicroVAX nicht immer korrekt gebootet hat, weil die CPU zu schnell aus dem Reset kam. Die Logik sieht offenbar vor, dass zuerst die Spannungen korrekt angelegt werden und erst mit einer gewissen Verzögerung an der braunen Leitung die "Power-Good" Spannung angelegt wird und auch die LED eingeschaltet wird. Die LED dient somit als Kontrolle, ob Power-Good eingeschaltet ist oder nicht.

Mein Freund Konstantin und ich haben auch festgestellt, und zwar mit einem funktionierenden Netzteil, dass die Power-Good Logik sowohl mit 5V als auch mit 12V getriggert werden kann. Wir haben einmal nur an 12V eine Last angeschlossen und einmal nur an 5V und beides hat den gewünschten Effekt erzielt, nämlich dass mit kurzer Verzögerung Power-Good eingeschaltet wurde und auch die LED an ging. Es geht offenbar nur um den "Reset" der CPU und weniger um eine echte Power-Good Kontrolle.

Das Problem mit der Power-Good / Reset Verzögerung gibt es offenbar öfters, weil man immer wieder im Internet liest, dass VAX Systeme dieser Generation, auch nachdem die Kondensatoren getauscht wurden, nicht immer korrekt booten.

@fanhistorie: Der LM339 hat Open Collector Ausgänge, die ohne PullUp nichts liefern. Die Schaltung von T2 und T3 existiert vermutlich, um eine saubere Trennung der Anzeige und des "wichtigen" Power-Good Signals zu haben, das direkt mit dem Gate-Array auf dem Mainboard verbunden ist.

Der Konstantin ist übrigends noch dabei, den Rest von dem Sekunärteil dieses Netzteils zu analysieren um heraus zu finden, wie hier tatsächlich die Lasterkennung funktioniert, die zum Einschalten der "Power-Good" Leitung führt

Liebe Grüße,
// Peter

Problem Gelöst!

Nachdem der Austausch des LM339N keinen Erfolg gebracht hat und auch die Schalttransistoren nicht defekt waren, hat ein guter Freund sich die Mühe gemacht und ein Reverse-Engineering von der Power-Good Schaltung gemacht:

Dadurch konnte dann schlussendlich der Defekt lokalisiert und behoben werden. Verursacher war der Widerstand R12 in der Zeichnung. Den hat offenbar die Korrosion gefressen. Nachdem der Widerstand getauscht wurde, funktioniert das Netzteil jetzt wie es soll und liefert, wenn etwas angeschlossen ist, mit der notwendigen Verzögerung das Power-Good Signal und schaltet die LED ein.

An dieser Stelle möchte ich gerne auf den YouTube Kanal von Konstantin Grigoriadis hinweisen, der diesen Power-Good Schaltplan erstellt hat:

https://www.youtube.com/channel/UCf7Oy-0eWMeFYZJuoGrUdjg

Danke lieber Konstantin!

Liebe Grüße

// Peter

Liebe Community!

Nachdem es das Internet nur bedingt auf die MicroVAX bzw. VAXstation mit ULTRIX 4.5 geschafft hat, habe ich mich daran gemacht und den NCSA Mosaic Browser dafür übersetzt:

HIer sieht man die "allerletzte" Version, die es vom NCSA Mosaic Browser für X-Windows gegeben hat. Diese Version 2.7b6 ist entstanden als der Mosaic Browser bereits offiziell eingestellt war:

Mosaic Web/Gopher Browser

Außerdem habe ich auch die Version 2.6 übersetzt. Das war die letzte offiziell unterstützte Version für X-Windows.

Für alle die, sich auch gerne mit einer MicroVAX oder VAXstation noch einmal zu den Anfängen des Internets wie wir es heute kennen begeben möchten, hier sind die Mittel dazu

Mosaic.7z

Viel Spass und liebe Grüße,

// Peter

Hallo!

fanhistorie Danke für die zahlreichen Tipps und Informationen. Ich werde mir die Power-Good Schaltung genauer ansehen und berichte natürlich was der Fehler war, wenn er behoben ist.

Interessant ist, dass es zu genau diesen PSUs kaum Informationen gibt. Die Teile wurden doch auch von Astec gebaut oder? Gibt es hier irgendwo Schaltpläne oder sonstiges oder ist das bis heute "streng geheim"?

Ich bin dankbar für alles, was das Leben hier erleichtert.

Liebe Grüße

// Peter

Die beiden Netzteile sind zwar vom Layout unterschiedlich, haben aber, soweit ich das eruieren konnte die gleiche Spezifikation. Das H7083-AB stammt offenbar original von einem InfoServer 150 und der ist praktisch baugleich wie die MicroVAX 3100, außer dass der keine FPU hat und die Stecker für die zusätzliche serielle Schnittstelle und die Speichererweiterung fehlen:

Mainboard von einem InfoServer 150:

Beide Netzteile haben einen LM339N:

Auf dem H7821-00 sitzt er hier auf der Zusatzplatine, an die auch die LED angeschlossen ist:

Und bei dem H7083-AB, ebenfalls in der Nähe der LED:

Hier sieht man auch ganz gut die anderen Bauteile die sich in der Nähe des LM339N befinden.

// Peter

Im eingebauten Zustand mit Mainboard und Laufwerken angeschlossen sieht das H7821-00 dann so aus:

Der braune Power-Good Pin liefert eine sinnvolle Spannung für das CMOS Gate-Array auf dem Mainboard:

Die LED ist jetzt an:

Die restlichen Spannungen bleiben zu niedrig - spannend dass der Rechner damit trotzdem funktioniert

// Peter

Das ist die Messung von dem funktionierenden H7821-00:

Im ausgebauten Zustand:

Die LED ist aus

Die Spannungen sind nicht berühmt (auch das H7821-00 braucht wohl neue ELKOS):

Beim braunen Power-Good liegt aber de-facto keine Spannung an:

// Peter

Ein paar Bilder zu der ganzen Geschichte:

Das H7083-AB Netzteil vor dem ELKO Tausch:

So sah das ganze dann aus, während dem Tausch:

So sieht das H7083-AB Netzteil mit den neuen ELKOS aus:

// Peter

Sowohl mit Festplatte als auch ohne. Wenn das PSU den braunen Pin verzögerz zuschaltet, startet der Rechner immer zuverlässig, wenn der Braune Pin von Anfang an Strom hat, ist es Glücksache. Inzwischen hab ich auf E-Bay jemanden gefunden, der offenbar das gleiche Problem auch mit einem H7821-00 in einer VAXstation hat. Das beantwortet zwar nicht meine Frage ob sich das H7083-AB gleich verhaltet wie das H7821-00, aber die wahrscheinlichkeit ist groß, nachdem der Fehler hier genau der gleiche zu sein scheint.

Ich werde einmal den LM339N beim H7083-AB tauschen ...

// Peter

Liebe Community!

Ich habe eine MicroVAX 3100 in der ursprünglich ein (als ich sie gekauft habe) ein H7083-AB Netzteil eingebaut war. Dort waren praktisch alle ELKOS tot und zur Sicherheit wurde auch der RIFA Kondensator ausgetausch, das minmiert die Brandgefahr

Ergebnis: Das Netzteil liefert perfekt alle Spannungen die es soll, allerdings hat meine MicroVAX 3100 damit Startprobleme.

Nach näherer Untersuchung habe ich festgestellt, dass das etwas mit dem Reset beim starten zu tun hat. Der braune Pin 7 vom Netzteil soll laut Anleitung zwischen +3,5V und +5,25V Spannung liefern. Das ist offenbar die "Power-Good" Leitung. Bei dem H7083-AB Netzteil, leuchtet die LED und die Power-Good Leitung liefert +5V. Wenn man dieses Netzteil nun einbaut und die MicroVAX damit startet, braucht man mehrere Versuche, bis dast Teil hoch kommt und oft liefert dann die FPU einen Fehler. Das Verhalten ist immer unterschiedlich. Das deutet auf ein Reset-Problem hin.

Um heraus zu finden was da sein kann, hab ich mir jetzt ein H7821-00 Netzteil besorgt und frolgendes festgestellt:

Betrieb ohne Last (im ausgebauten Zustand):

Power-Good => 102,5mV

LED => Off

12V => 11,04V

-12V => -11,38V

5V => 4,77V

9V => 8,51V

Betrieb mit Last (im eingebauten Zustand):

Power-Good => 3,75V

LED => On

12V => 11,39V

5V => 4,54V

Die restlichen Spannungen habe ich im eingebauten Zustand nicht gemessen, aber trotz den zu niedrigen Spannungen auf allen Anschlüssen startet der Rechner immer sofort und Zuverlässig. Die zu niedrigen Spannungen sind vermutlich auch auf defekte ELKOS zurück zu führen und außerdem hat das Teil auch noch einen RIFA Kondensator, der wohl auch ersetzt werden sollte, denn von denen hab schon welche im wahrsten Sinne des Wortes abbrennen gesehen

Beim H7821-00 PSU ist die LED vom Netzteil an einer kleinen Zusatzplatine angeschlossen, auf der sich auch ein LM339N Chip befindet. Bei dem H7083-AB PSU befindet sich ebenfalls so ein Chip in der Nähe der LED. Das Teil ist laut Datenblatt ein Quad differential comparator.

Fazit: Beim H7821-00 PSU wird das Power Good Signal erst dann eingeschaltet wenn etwas angeschlossen ist und dann geht auch die LED an. Beim H7083-AB PSU ist die grüne LED sofort an, auch ohne LAST und das Power-Good Signal ist ebenfalls sofort da. Das erklärt aus meiner Sicht auch den Startfehler des Rechners.

Jetzt meine Frage:

Soll sich das H7083-AB exakt gleich verhalten wie das H7821-00 im Bezug auf die LED und das Power-Good Signal?

Danke und liebe Grüße,
// Peter

Auch auf einer MicroVAX 3100 läuft DECwindows unter ULTRIX 4.5, wenn man xdm von den UNSUPPORTED Paketen nachinstalliert. Man muss sich mangels eingebauter Grafik Hardware zu der MicroVAX 3100 einfach mit einem X-Display über Netzwerk verbinden:

Da werden Erinnerungen wach

Der OSF/Motif Window Manager ist allerdings ein bischen zickig mit der Maus. Unter Debian 10 funktioniert es mit Xephyr problemlos, unter Windows 10 hab ich die Maus nur mit Cygwin/X korrekt zum funktionieren gebracht, zum Beisiel mit VcXsrv hat es nicht funktioniert. Da kann man beim mwm weder die Fenster verschieben, noch die Größe ändern, der twm funktioniert auch mit VcXsrv unter Windows 10 einwandfrei.

Liebe Grüße
// Peter

Für Ultrix 4.5 gibt es von DEC einen Y2K Patch, was das System auch heute noch durchaus im Alltag benutzbar macht:

# uname -a
ULTRIX mvax3100 4.5 0 VAX
# date
Mon Aug  1 19:50:15 WET DST 2022
#

Damit ist es neben 2.11BSD, eines der wenigen historischen UNIX Systeme für DEC Rechner, die es ins 21. Jahrhundert geschafft haben.

Liebe Grüße

// Peter

Falls noch nicht bekannt, so kann man den passenden PAK für "lmf" für Ultrix 4.5 erzeugen:

$ cc pakgen64.c -o pakgen64
$ ./pakgen64 ULTRIX -p DEC -i DEC -a ALS-WM-93176-10007 -c K -N

Das File "pakgen64.c" findet man schnell, wenn man danach sucht und das Ergebnis ist durchaus brauchbar:

# lmf
lmf> list
Product                   Status                     Users: Total      Active

ULTRIX                    active                            unlimited
lmf>

Liebe Grüße

// Peter

Falls noch nicht bekannt unter Debian10 kann man die Ultrix CD so mounten:

$ sudo mount -t ufs -o ro,ufstype=sun,loop /dev/sr0 /media/cdrom
$ cd /media/cdrom/
$ ls -l
insgesamt 2339
drwxr-xr-x 2 root root    8192 Okt 21  1995 lost+found
-rw-r--r-- 1 root root   18176 Okt 18  1995 ultrixboot
drwxrwxr-x 5 root root     512 Okt 21  1995 VAX
-rwxr-xr-x 1 root root 2353152 Okt 18  1995 vmunix
$

Liebe Grüße
// Peter

Nachdem keiner der CTI Slots markiert ist, tippe ich auf einen RAM Fehler bei einem der beiden onboard RAM Module oder auf einen losen Patch am Motherboard, der jetzt anstatt richtig verlegt und verklebt, direkt auf einem Chip liegt und dort durch Übersprechen diverse Fehler verursacht. Das war zumindest bei dem Pro350 von einer lieben Kollegin von mir der Fall.
// Peter

Inzwischen gibt es neue Erkentnisse zum PRO/VENIX 2.0 Kernel

Der Teufel versetckt sich im "tty.o" Treiber

pk@dell-e7250-pk:~/simh-venix11/dist/work/ProVenix20/usr/sys/OSLIB11$ for i in `ls -1 *.o`; do echo -n $i" : "; strings $i | grep "too many"; echo ""; done
acct.o :
alloc.o :
bio.o :
clock.o :
disk.o :
fio.o :
iget.o :
ipc.o :
lockf.o :
main.o :
malloc.o :
mem.o :
msg.o :
nami.o :
pipe.o :
prf.o :
rdwri.o :
sem.o :
sig.o :
slp.o :
strings.o :
subr.o :
sys1.o :
sys2.o :
sys3.o :
sys4.o :
sys5.o :
sysent.o :
text.o :
tty.o : too many users

utssys.o :
pk@dell-e7250-pk:~/simh-venix11/dist/work/ProVenix20/usr/sys/OSLIB11$

An sich ein guter Platz, für diesen Zweck!

Hier noch ein Bild meiner aktuellen "hybriden" Venix Entwickungsumgebung:

// Peter

Die DEC Professional Computer waren der Versuch von Digital, mit PDP11 basierten PCs dem IBM PC Konkurrenz zu machen. Das hat, wie wir heute wissen nicht wirklich funktioniert

Trotzdem sind die DEC Professional Comuter ein sehr nettes Stück Computergeschichte und quasi der PDP11 für den Schreibtisch.

Als Unixer kommt man da praktisch kaum dran vorbei, denn immerhin ist der PDP11 ja quasi die Heimat von Unix.

Man findet immer wieder auch Geräte bei E-Bay:

https://www.ebay.de/itm/154912…ksid=p2060353.m1438.l2649
https://www.ebay.de/itm/144452…0353.m1438.l2649%E2%80%8B

Aber ja stimmt, wirklich viele sind davon nicht mehr vorhanden.

Falls jemand inzwichen auch PRO/VENIX 2.0 installiert hat, wäre es toll, wenn jemand mein kleines Progamm aus dem Anhang dort umwandeln und testen könnte!

Wenn das nämlich generell funktioniert, werde ich ein keines Tool erstellen mit dem man diese Parameter ändern kann:

# cc -DVENIX -O test2.c -o test2
# ./test2
Hostname: pro380pk
SerialNo: DEC00100
MaxUsers: 2

// Peter

Inzwischen hat die Version auch ihren Weg zu TUHS gefunden

https://www.tuhs.org/Archive/Distributions/UCB/2.9BSD_MSCP/

// Peter

Hier alles, was geändert bzw. ergänzt werden musste damit man den PRO/VENIX 2.0 Kernel erzeugen kann:

usr_sys.zip

1.) Das "tar" Archiv muss zunächst auf den Pro, das funktioniert am einfachsten mit "kermit". Um auf Nummer sicher zu gehen, vorher mit "uuencode" in ASCII umwandeln und dann auf dem Pro wieder mit "uudecode" zurück. An sich macht PRO/VENIX, 8-Bit auf den seriellen Schnittstellen, wer allerdings an Unix gewöhnt ist, vertraut hier eher auf "uuencode"

2.) Dann muss man das "tar" Archiv als Benutzer "root" im Verzeichnis "/" mit "tar xvf usr_sys.tar" entpacken.

3.) Danach kann man den Venix Kerrnel wie folgt erzeugen:

SUPER: PATH=$PATH:.;export PATH
SUPER: echo $PATH
/bin:/etc:/usr/bin:.
SUPER: cd /usr/sys/conf
SUPER: pwd
/usr/sys/conf
SUPER: make install
=== Making venix for PRO 380 ===
        config -m master params.p380
        cc -c -I/usr/include conf.c
        mv conf.o c.p380.o
        cc -c -DMACH='"PRO380\0 "' -DVERS=\"`/usr/bin/date +%y%m%d%H`\" -I/usr/include uts.c
        mv uts.o uts.p380.o
        ld -k -i -X -x -u _sureg -u _mapallo low.pro.o c.p380.o \
                ../MDLIB.11.p380 ../IOLIB.pro ../OSLIB.11 uts.p380.o last.o
        kfix a.out venix.p380
        vstrip11 venix.p380
        rm a.out
        chmod 444 venix.p380
=== venix is now made ===
        mv venix /venix.test
=== Reboot next on "venix.test" and rename it "venix" when verified ===
SUPER:

Anpassen kann man die Parameter in der jeweiligen Datei "params.xxx". In meinem Fall habe ich den Kernel in der Datei params.p380 auf 50hz eingestellt.

// Peter

Zubnächst einmal der fehlende Teil, damit sich der Venix Kernel bauen lässt:

/*
 * uts.c: reconstruction to configure a new Venix kernel
 *
 * This file contains mainly the same as utsname.c, but
 * with some predefined values which will be shown with:
 *
 * uname -a
 * VENIX pro380pk SysVr2.0 85061411 PRO380 DEC00100
 *  SYS    NODE     REL      VERS    MACH    SER
 *
 * The definitions have been adapted to match exactly with
 * the values in the original Venix kernel.
 *
 * Peter Klapper, 01.05.2022
 *
 */

#include <sys/utsname.h>

#ifndef SYS
#define SYS  "VENIX\0  \0"
#endif
#ifndef NODE
#define NODE "        \0"
#endif
#ifndef REL
#define REL  "SysVr2.0\0"
#endif
#ifndef VERS
#define VERS "22000001\0"
#endif
#ifndef MACH
#define MACH "PRO380\0 \0"
#endif
#ifndef SER
#define SER  "        \0"
#endif

struct utsname utsname = {
        SYS,
        NODE,
        REL,
        VERS,
        MACH,
        SER,
};

Wie man sieht, ist sowohl "NODE" als auch "SER" hier nur mit "Leerzeichen" befüllt. VERS wird im originalen Makefile mit Datum+Stunde befüllt. Das habe ich im Makefile zunächst deaktiviert.

// Peter

Hallo Torsten, vielen Dank für die Info - diese Version ist für den Intel 386 und bereits eine Generation neuer - aber trotzdem Danke!

Nach einigen kleineren Anpassungen in der rekonstruierten uts.c Datei konnte zunächst der Originalkernel exakt reproduziert werden:

pk$ ls -l /venix*
-rw-r--r--   1 bin      bin       100336 Jun 19  1985 /venix
-r--r--r--   1 root     sys       100336 Apr 30 12:56 /venix.test
pk$ uname -a
VENIX pro380pk SysVr2.0 22000001 PRO380 DEC00100
pk$

Lediglich die Versionsnummer ist eine andere, damit man die Teile auseinander halten kann

Inzwischen ist auch klar, dass man weder die Seriennummer, noch die Anzahl der User über uts.c ändern kann. Das wäre ja auch zu einfach gewesen und geht dann wohl nur über die "spezielle" Venix Partition auf der Festplatte. Bevor ich aber beginne hier herumzubasteln, werde ich versuchen den "slu" treiber für meine 4-Fach serielle Karte einzubinden. Prüfen tut diese Venix Version die Anzahl der erlaubten User übrigens über die Anzahl der aktiven "getty" Prozesse. Wenn man mehr als zwei davon aktiviert, kommt auf der Console sofot: "too many users"

// Peter

Bingo! Die rekonstruierte Version von uts.c lässt den Venix Kernel bauen:

SUPER: make
=== Making venix for PRO 380 ===
        config -m master params.p380
        cc -c -I/usr/include conf.c
        mv conf.o c.p380.o
        cc -c -DMACH='"PRO380\0 "' -DVERS='"`date +%y%m%d%H`"' -I/usr/include uts.c
        mv uts.o uts.p380.o
        ld -k -i -X -x -u _sureg -u _mapallo low.pro.o c.p380.o \
                ../MDLIB.11.p380 ../IOLIB.pro ../OSLIB.11 uts.p380.o last.o
        kfix a.out venix.p380
        vstrip11 venix.p380
        rm a.out
        chmod 444 venix.p380
=== venix is now made ===
SUPER:

Ob er sich auch booten lässt wird sich zeigen

// Peter

Inzwischen ist die wiederhergestellte Venix Version auch offiziell im TUHS Archiv verfügbar:

https://www.tuhs.org/Archive/D…s/DEC/Venix/ProVenix_2.0/

// Peter

... Fortsetzung!

Das "neue" PRO/VENIX V2.0 hat sich für mich als das beste Betriebssystem für den DEC Professional 380 herausgestellt. Es ist ein vollständiges UNIX System V und lässt eigentlich nichts zu wünschen übrig. Ich habe inzwischen auch die "man" Pages vom System V 2.0 auf meinen Pro380 übertragen (die waren ja offiziell nie Bestandteil von Venix).

Jetzt habe ich begonnen, mich damit zu beschäftigen, meine 4-Fach RS232 Karte auf meinem Pro380 zu laufen zu bringen. Dazu muss man den Venix Kernel neu konfigurieren, denn im Stand-Kernel ist der Treiber dafür, leider nicht enthalten. Er ist aber im Lieferumfang von PRO/VENIX 2.0 dabei.

Leider fehlt bei den vorliegenden Kernel-Komponenten, die Datei "uts.c", weshalb sich der Kernel mit dem Treiber für die 4-Fach RS232 Karte nicht erzeugen lässt. Bei UNIX Sytem V gibt es im Quellcode eine Datei "utsname.c" in der diverse Parameter gesetzt werden, die man dann mit "uname -a" abfragen kann. Bei Venix sind das in meinem Fall:

SUPER: uname -a
VENIX pro380pk SysVr2.0 85061411 PRO380 DEC00100

Um einen Kernel konfigurieren zu können muss also diese Datei "uts.c" irgendwie rekonstruiert werden. Es reicht aber nicht, ganz einfach die Datei "utsname.c" aus dem System V Quellcode in "uts.c" umzubenennen. Einerseits gibt es das Element Seriennummer bei "utsname.c" überhaupt nicht und andererseits sind im Venix Kernel auch gar nicht alle Parameter gespeichert, die man mit "uname -a" abfragen kann.

Somit habe ich ich mich auf die Suche begeben, wo der Rest gespeichert sein könnte, den man mit "uname -a" abfragen kann und natürlich auch, wo das System die Anzahl der "User" festlegt. Ich bin dabei unter "/dev/w0.venix" fündig geworden:

Noch ist das Puzzle nicht gelöst, aber zumindest ergibt das Ganze schon einen gewissen Sinn

// Peter

Hallo Volker,

falls du noch einen Harddisk Contrlller für Deinen Pro350 suchst:

https://www.ebay.com/itm/29493…69e875:g:0loAAOSwB75iXbkr

Die Teile sind ja inzwischen recht selten geworden.

Liebe Grüße,

// Peter